Service-Oriented Architecture is, as the name suggests, a style of writing software that focuses on units as services. A {\bf service} is similar to a component or a module in that it encapsulates data and functionality while presenting only an interface to the rest of the program \cite{msdn}.

A Service-Oriented Architecture is composed of three parts: a service provider, a service consumer, and a registry. Providers supply the services and expose them through the registry. Consumers can see the registry and invoke the services as described by the registry.\cite{huhns} A Service-Oriented Architecture can then be separated into three architectural views: The application architecture, the service architecture, and the component architecture \cite{msdn}.
\begin{itemize}
\item Application architecture \\
The application architecture describes the consumer of one or many services. It does not consider the environment or the implementation of the services, or how the service layer aggregates smaller services into the exposed set of course-grained services.
\item Service architecture \\
The service architecture is concerned with what services are available, and how they are invoked. It is not concerned with any consumers of the services. It is responsible for specifying service contracts. It is prudent to organize similar services together.
\item Component architecture \\
The component architecture describes how everything under the service layer is implemented. It is not concerned with how its services are exposed. It must consider its implementation and environment. It cannot know how many consumers, if any, are using the service it publishes.
\end{itemize}

It is important to note that Service-Oriented Architecture is not the process of exposing every software component as a web service. While web services can be an example of Service-Oriented architecture, services are independent of any specific technology. Service-Oriented Architecture is an architectural style or a business strategy, not a specification or a protocol. \cite{draheim} While web services are often confused with SOA, they are not the same. There are many services that are not exposed via the web, and it is quite possible to expose something via web services that is not truly a service. If a database is exposed to use CRUD (Create, Read, Update, and Delete) operations via Web Services, this is not a true service. In this case, the client is responsible for maintaining data integrity. The service is not properly self-contained.\cite{msdn}

In particular, a service should exhibit the following properties:

\begin{itemize}
\item {\bf Loose Coupling} Consumers of services cannot be coupled with a service provider. A service provider should be able to be swapped out with another, provided that their interfaces and contracts are the same.
\item {\bf Implementation Independence} An application built on services cannot depend on specifics of the implementation of a service, such as programming language. This is especially important when integrating legacy applications as services \cite{huhns}
\item {\bf Persistence of Services} Service providers must be reliable, as a service consumer relies on the provider.
\item {\bf Granularity} It is not appropriate to expose services at a 'fine-grained' level. If a service provider exposes many fine-grained actions, it is likely to create dependencies. It becomes more difficult to swap another service in, and changes to the provider affect all clients. Therefore, service providers should expose themselves at a 'course-grained' level: providers should restrict themselves to fewer, more general actions.\cite{huhns}
\item {\bf Standardization} While it is not possible to specify the semantics of every possible exchange, it is certainly possible to standardize the syntax. Like web services, service providers and consumers must speak the same languages.\cite{msdn}
\item {\bf Formal} Services must bind themselves to a formal contract of services. Consumers cannot see more than what is exposed through the registry, so there should be sufficient information to ensure reliability.\cite{msdn}
\end{itemize}

A service is also defined by its contract. As explained above, a service can only let a consumer know the semantics of its use via what is exposed in the repository. Therefore, the repository must contain a formal contract that lets the consumer know exactly how to use the service. A consumer should be able to switch producers without having to change at all.

There are two ways in which contracts can be formed: negotiated contracts or instantiated contracts.\cite{msdn} Negotiated contracts are formed when a producer and a consumer are both being developed at the same time. Both sides can have a say in what the contract and the interface should be. This most often occurs in new Service-Oriented Architectures. Instantiated contracts occur when only one side dictates the interface and the contract. This can occur when a producer exists before a consumer, or vice versa.

Additionally, most service providers and consumers have a Service Level Agreement (SLA) which dictates the quality of the service. These are necessary as, most likely, the entity responsible for the service provider is not the entity responsible for the service consumer, and so the consumer must have some guarantee of quality from the provider. SLAs must have certain properties to be viable.\cite{slabook}

\begin{itemize}
\item{\bf Reasonable} The requirements in an SLA should motivate the developers of both the service provider and service consumer to produce a quality architecture.\cite{slabook}
\item{\bf Attainable} The requirements should be possible. It isn't reasonable to ask the service provider to control for use of resources by other parties, such as latency in distributed systems.\cite{slabook}
\item{\bf Objective} It should be possible to interpret the requirements in only one way.
\end{itemize}

SOA can be utilized during the inception of a new project, or as a way to help maintain legacy applications while expanding them. This will be discussed further in the use case section.